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ABSTRACT 


As DOD increases their reliance on space assets, a call for doing more for less has 
been initiated. Requests for more capability will present opportunities in technological 
advancements including methods for controlling those assets. Constrained by a educa 
budget, the decision maker must be able to properly evaluate systems and select the best 
candidate. For Telemetry, Tracking, and Commanding (TT&C), the decision maker 
needs an objective methodology capable of aiding in the evaluation of TT&C systems. 
The thesis provides such an essential tool that will aid in the assessment of proposed 

TT&C architectures. The first section describes the process of TT&C by using activity 
modeling to describe the key functions and the present interrelationships among these key 
functions. To provide an initial basis of understanding, three current TT&C architectures 
- were discussed: Air Force Satellite Control Network, Mission Control Center Johnson 
Space Center, and Naval Satellite Operations Center. This enabled the authors to 
highlight favorable trends utilized for enhancing performance. The thesis concludes with 
a demonstration of an objective methodology based on the Analytic Hierarchy Process. 
This approach resulted in the ability to provide a weighted ranking of proposed TT&C 


architectures and was illustrated using current architectures. 
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I. INTRODUCTION 


A. PURPOSE OF THESIS 


The purpose of this thesis is to present the decision maker with an objective 
methodology that can be used in determining the selection of a most favorable Telemetry, 
Tracking, and Commanding (TT&C) architecture. It has been observed that a need exists 
to integrate the current satellite control network in order to achieve a higher degree of 
efficiency. To do this, the decision maker requires four elements; a set of joint 
requirements, a system architecture, an implementation plan, and a cost operational 
effectiveness analysis (COEA). Currently, DOD lacks an adequate set of requirements, 
has no common system and therefore no implementation plan, and lastly lacks adequate 
information to put together an effective COEA. This thesis emphasizes identifying a 
generic TT&C system architecture and the development of a method to objectively 


compare two or more candidate architectures for future implementation. 


B. METHODOLOGY 


In order to better understand the problems associated with evaluating Telemetry 
Tracking and Commanding (TT&C) architectures, the major issues that effect TT&C 
systems will be discussed. Then, a discussion of a generic TT&C process will be 
examined followed by a description of three well known existing architectures, the Aur 
Force Satellite Control Network (AFSCN), Mission Control Center (MCC), and Naval 
Satellite Operations Center (NAVSOC). Lastly, an objectively based scaling criteria is 
developed and presented along with an illustrated example using the AFSCN, MCC, and 


NAVSOC architectures to better clarify the concepts of the methodology. 


C. SCOPE OF THESIS 


The main focus of this thesis is to present a useful methodology for evaluating 


current and future TT&C architectures. A general discussion of issues that affect these 








architectures will be given to characterize the environment. The thesis will only address 
those issues that affect generic TT&C systems. The objective methodology is presented 
along with an illustration using the AFSCN, MCC, and NAVSOC architectures as they 
exist at the time of this writing. As a result of the unavailability of actual values, all 


values associated with the illustration are chosen for illustrative purposes only. 


D. BACKGROUND AND ISSUES SURROUNDING TT&C 


Before proceeding, it is important that the reader have an understanding of the 
studies and publications currently effecting DOD Space agencies and TT&C architectural 
development. This brief background will provide the foundation for the rest of the 


material presented in this thesis. 


1. Future Integrated TT&C Architecture Study 


a. History 

Early in 1993, Congress viewed satellite control as too costly and in January of 
1994, the Joint Staff/J6 directed the United States Space Command (USSPACECOM) to 
lead in the development of the Future Integrated TT&C Architecture Study (FITAS). 
About the same time, the General Accounting Office (GAO) requested the use of the 


FITAS to aid in the evaluation of the Fiscal Year (FY) 96 Appropriations. 


b. Purpose 

Originally USSPACECOM — directed to do the following: (1) develop a 
comprehensive architecture and roadmap for an integrated DOD satellite control 
infrastructure; and, (2) reassess the Office of the Secretary of Defense (OSD) policy for 


application of MIL-STD-1582C, Satellite Data Link Standard: Uplinks and Downlinks. 








However, in a counter proposal accepted by the Director Joint Staff, USSPACECOM 
opted to emphasize interagency ties first, then to address high level system features with 
the increased economy of making resources accessible for sharing across all participating 
agencies as a goal. [Ref. 1] 

In order to accomplish this task five panels were organized and supervised by a 
Senior Steering Group (SSG). Each of the panels addressed one of the following: 


Requirements, Current Status, Evaluation Criteria, Fusion, and Implementation. 


c. Summary of Findings 

Findings from the FITAS revealed several factors, some of which will be 
discussed here. It was determined that the existence of a central authority to develop 
interagency satellite control guidelines was not readily accessible. The lack of mutual 
interagency interaction and a means to establish satellite control changes across the 
organizations needs to be examined. In a related issue, it was determined that 
organizations have evolved their own set of requirements and that benefits may lie in the 
development of universal requirements. The complexity of the Air Force Satellite 
Control Network (AFSCN) software maintenance program and their manpower intensive 
approach to satellite control was also addressed. For a complete discussion on the FITAS 


findings see Reference 1. [Ref. 1] 


d. Conclusions 


The completion of the FITAS touched on ten key concepts which involved the 
development of a long-term integrated DOD satellite control architecture and increased 
interagency satellite resource sharing. The ten concepts discussed are: (1) Management 
Structure, (2) First Plug-N-Use Tier, (3) Second Plug-N-Use Tier, (4) S-Band Exclusive 
Use of the Second Plug-N-Use Tier, (5) Use of In-Band commanding, (6) Frequency 
allocation issues, (7) Wave form or frequency changes, (8) AFSCN transition to 
distributed processing, (9) Manning reductions, (10) MIL-STD-1582C. The authors have 


decided to present those concepts most pertinent to the development of this thesis. 


(1) First Plug-N-Use Tier: An initial overall effort to make common TT&C 
functions of individual systems accessible. The first tier is intended to permit all Defense 
Satellite Control Network (DSCN) nodes to produce and receive mutually understandable 


and useful information for all DSCN services. [Ref. 1] 


(2) Second Plug-N-Use Tier: Intended for TT&C and mission data 
operations that will need to plug into the evolving Defense or National Information 
Infrastructure (NII) wherever possible for economy of scale end access to all other DSCN 
nodes. New systems , and those undergoing upgrades, will be required to conform 
immediately. International commercial standards will be used to the maximum extent 


possible. [Ref. 1] 








~ (3) AFSCN transition to distributed processing. The AFSCN must 
transition to object oriented, distributed processing. To capitalize on reduced software 
development costs and software that already exists or is being developed for TT&C, 


communications, scheduling, and so on. [Ref. 1] 


(4) Manning reductions. Reduction in On-Console, Communication, and 
Real-time Engineering Support. On console manning could be reduced by up to 33%. 
Communication manning could be reduced by up to 45%. Real-time engineering support 


for trend monitoring and anomaly resolution could also be greatly reduced. [Ref. 1] 
2. Objective Technical Architecture Overview 


a. History 

The Objective Technical Architecture (OTA) was established to ensure both the 
North American Defense Command (NORAD) and USSPACECOM remain a viable 
force structure. The operational requirements document (ORD) was designed to provide 
the needed guidance in the acquisition of advanced technology and infuse that 
technology into NORAD and USSPACECOM Integrated Command and Control System. 

By definition the OTA describes a minimal set of rules governing the 
arrangement, interaction, and interdependence of the parts or elements that together may 
be used to form an information system, and whose purpose is to ensure that a conformant 


system satisfies a specified set of requirements. [Ref. 2] 








The OTA is divided into five sections; (1) purpose, background, and scope; (2) 
the Elements of NORAD / USSPACECOM OTA and infrastructure; (3) identification of 
a set of standards guidance profiles based on OTA - Technical Reference Model (OTA 
TRM); (4) explanation of the management approach for the OTA; (5) examples of how 


to use the OTA within the acquisition of information systems. [Ref. 2] 


b. Purpose 


The OTA is designed to provide guidance while defining, designing, and 
developing those systems that will become a part of NORAD and USSPACECOM 
Integrated Command and Control System. In addition, the OTA provides guidance to 
agencies and staffs that are involved in the directing and managing modifications of 
existing NORAD / USSPACECOM systems. Lastly, the OTA guides those involved in 
the testing, integrating, certifying, and training or maintaining new systems or modified 
systems. [ Ref. 2] 

It should be noted that the OTA applies to NORAD, USSPACECOM, Arr Force 
Space Command (AFSPC), United States Army Space Command (USARSPACE), Naval 
Space Command (NAVSPACECOM), Canada, and the United Kingdom. While the 
guidance sontaned within the OTA applies to all those involved in requirements 


definition and analysis. [ Ref. 2] 





c. Summary of Findings 

For the purpose of this thesis, the authors will summarize sections two and three 
which covers both elements and standards. The Command, Control, Communications, 
Computer and Intelligence for the Warrior (C4IFTW) tenants provide the bases for the 
OTA operating perspective. The eight tenants of C4IFTW are expounded on within the 
OTA and are listed here for simplicity; 100 % interoperability, Common Operating 
Environment (COE), Flexible modular C4I packages, Horizontal and vertical C2, CINC 
pull on demand, Real - time decision aiding, Global resource management and control, 
and Seamless operations. 

Along with the above tenants, the OTA emphasizes a set of design and 
development principles that aid in broadening the development of mission requirements 
that include configuration management, testing and certification, training and simulation, 
security, reliability, maintainability, robustness, business processes and data 
standardization. 

Consistent with the direction from the William Perry letter, Specifications & 
Standards -- A New Way of Doing Business, dated 29 June 1994, the OTA standards 
guidance reflects the standards currently used in existing operational systems and / or 
systems currently being developed. [Ref. 2] 

The OTA standards guidance stresses the importance of migrating to open 
systems and provides four types of performance-based criteria: commercial item 


descriptions (CIDs), guide specifications, standard performance specifications, and 


program peculiar specifications. These specifications would develop into standards for 
use in future systems. The criteria to achieve this appears throughout the OTA guidance 


profiles. [Ref. 2] 


3. DOD Technical Architecture Framework for Information Management 


a. History 

The Technical Architecture Framework for Information Management (TAFIM) 
provides guidance necessary to establish a DOD wide framework required to manage 
multiple technical architecture initiatives. The TAFIM is intended to influence three 
areas: the use of common principles, assumptions, terminology in DOD Component 
(Services, Agencies, and CINCs) technica] architectures; the definition of a single 
structure for the DOD technical infrastructure components (system components) and how 
they are managed; and the development of information systems in accordance with 


common principles to permit DOD wide integration and interoperability. [Ref. 3] 


b. Purpose 


The TAFIM provides guidance for the evolution of the DOD technical 
infrastructure by focusing on the following: services, standards, design concepts, 
components and configurations. These elements guide the development of technical 
architectures to meet specific mission requirements. It should be pointed out that the 


TAFIM does not provide a specific system architecture. [Ref. 3] 











Important to architecture design, the TAFIM introduces concepts such as 
interoperability, portability, and scalability of DOD information systems. The TAFIM 
assumes that information systems will and must interoperate at some time. [Ref. 3] 

With proper implementation, the TAFIM guidance should achieve the following 
results: promote integration, interoperability, modularity, and flexibility; guide 
acquisition and reuse; and speed delivery of information technology and lower its costs. 
[Ref. 3] 

The TAFIM is divided into eight volumes that represent the varying states of 
development and maturity: (1) Overview, (2) Technical Reference Model, (3) 
Architecture Concepts and Design Guidance, (4) Implementation Manual, (5) Support 
Plan, (6) DOD Goal Security Architecture, (7) Standards Profile and Implementation 
Guidance, and (8) DOD Human Computer Interface (HCI) Style Guide. [Ref. 3] 

Of particular importance to this thesis is Volume 3, Architecture Concepts and 
Design Guidance. Volume 3 provides concepts and design guidance that will help 
architects, integrators, and system designers to develop information systems technical 
architectures and are considered in the context of the Technical Reference Model found in 


Volume 2. The key elements found in this volume are in the following section. [Ref. 4] 
c. Summary of Findings 
Volume 3 of the TAFIM series describes several models in varying degrees of 


detail. These models include: the Architecture Models, Client / Server Models, 


Host-Based Models, Master-Slave and Three-Tiered Models, Peer-to-Peer Models, 
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Distributed Object Management Models, Database Management Systems (DBMS) and 
Data Models. [Ref. 4] 

The volume also defines several key elements involved in developing 
information architectures such as Data Security. Data security includes measures that are 
implemented to prevent unauthorized access, modification, use, and dissemination of data 
stored or processed by a computer system. Data security also includes data integrity, and 
protecting the system from physical harm. 

The Open System Interconnection (OSI) Reference Model is used for data 
communications in the TAFIM. The model consists of the following seven layers: (1) 
physical layer, (2) data link, (3) network, (4) transport, (5) session, (6) presentation, and 
(7) application. The seven layers are structured to facilitate independent development 
within each layer and to provide for changes independent of other layers. [Ref. 4] 

Lastly, the volume provides an overall Design Guidance for use by all 
developers of information systems. The following are guidelines for designing specific 


architectures; 


e An architecture will contain components to implement only those reference 


model services that it requires. [Ref. 4] 


® Components may implement one, more than one, or only part of a service 


identified in the reference model. [Ref. 4] 
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¢ The components should conform to the profile standards that are relevant to the 


services they do implement. [Ref. 4] 


E. OUTLINE OF CHAPTERS 


1. Chapter II. Defining the Core TT&C Elements 


In this chapter, a description of a generic TT&C system is provided to aid the 
decision maker in understanding the process involved. To achieve this, the most basic 
elements in the area of telemetry, tracking, and commanding are defined. A discussion 
on the primary functions and their relationship between one another is conducted. The 
relationships identified in the TT&C process are further illustrated through graphic 


modeling. 


2. Chapter III. Current Methods and Trends 


In this chapter, the authors present a background on three well known U.S. TT&C 
facilities utilized by the DOD: Air Force Satellite Control Network (AFSCN), Mission 
Control Center (MCC), and the Naval Satellite Operations Center (NAVSOC). The 
background includes a look at the historical development, command structure, personnel, 
and operational methodology used by each facility. The trends in TT&C architectures are 
then highlighted and are used as an aid in the formulation of the comparison 


methodology. 


3. Chapter TV. Comparison Methodology 


In this chapter, the actual technique for comparison is presented. The process 
presented is an objective approach that is intended to be a useful step by step 
methodology that will produce valuable information for the decision maker about which 


candidate architecture should be selected amongst a number of alternatives. Each step is 
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illustrated in an example conducted using the AFSCN, MCC, and NAVSOC 


architectures. 


4. Chapter V. Conclusions and Recommendations 
As stated in its title, this chapter will provide a summary that highlights essential 


ideas discussed and recommend areas of further study. 
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II. DEFINING THE CORE TT&C ELEMENTS 


A. INTRODUCTION 


Although there exist numerous sources concerning TT&C, there has been little or 
no work done in attempting to analyze the process of conducting TT&C. The primary 
reason for understanding this process is to ensure TT&C is conducted as effectively and 
efficiently as possible. Secondly, it will provide the decision makers a more through 
understanding of this process to enable them to make sound judgmental choices in the 
procurement of future systems. This is accomplished by providing a basic definition of 
TT&C, identification and mapping of functional areas, and lastly the identification of 
common system drivers. This chapter will provide the above aids to the decision maker 
and will be used in subsequent chapters to examine the overall TT&C process and its 


associated measures of performances (MOPs) and measures of effectiveness (MOEs). 


B. DESCRIPTION OF A GENERIC TT&C ARCHITECTURE 


As the name implies, the most fundamental functions of TT&C are telemetry, 
tracking, and commanding. In order to utilize a space vehicle (SV) one must first be able 
to locate it and then track it. Next, one must be able to communicate with it and 
command the SV to carry out its functions. Lastly, one must be able to obtain data 


(telemetry) from the SV. 


1. Telemetry 
The telemetry of a SV consists of measurements taken onboard by the SV sensors 
and then transmitted to either a ground facility or spaceborne receiver. The two basic 


types of telemetry are analog or digital. The most common forms are: 


® High-Level Analog 


A telemetry channel with information encoded as an analog voltage. 
These are active analog inputs in that the command and data handling 
system does not provide measurement excitation. Data handling 
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equipment converts this information to digital form. 
[Ref. 5] 


¢ Low-Level Analog 


A telemetry channel with information encoded as an analog voltage. The 
signal range is such that amplification is needed before the information is 
encoded into digital form. [Ref. 5] 


e Passive Analog 


A telemetry channel with information encoded as a resistance. The 
command and data handling system supplies a constant current to the 
resistive sensor and encodes the resulting IR voltage drop into a digital 
word. [Ref. 5] 


e Bi-Level (Discrete) Input 


A telemetry channel conveying two state information (such as on/off or 
enable/disable). Information is encoded as voltages, but may be encoded as 
a resistance or presence or absence of a signal. [Ref. 5] 


® Serial Telemetry (Digital) Interface 


A 3-signal interface used to transfer digital data from an external source to 
the data handling equipment. The command and data handling system 
provides a shift clock and an interface enable signal to control data 
transfer. [Ref. 5] 


Telemetry is essential because it establishes a communication path downlink from 
the SV to the ground station. This allows the ground station to receive health and status 
of the SV which would include some of the following: voltages, currents, and 


temperatures. In addition, mission/payload related data would be downlinked to the 


ground station to be later processed and disseminated to the user. 


2. Tracking 


Space vehicle tracking involves locating a specific SV and then following its 


movement through space as a function of time. The position of the SV as a function of 
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time is determined by the use of the following measurements: elevation, azimuth, range, 
and range rate. Once the SV is acquired, the ground station can then point the receiving 

antenna at the SV to receive the telemetry data. Once the ground station begins to receive 
the telemetry, most antennas will automatically track the acquired SV maintaining 


maximum signal strength. [Ref. 6] 


3. Commanding 


Commanding is the method of controlling the SV from the ground while in 
line-of-sight of a ground station. SV commanding is important for many reasons. 
Commands transmitted to a satellite turn on or off such things as thrusters, sensors, 
recorders, etc. SV commands may also accomplish an attitude maneuver or an orbital 
adjustment maneuver. 

The four primary methods of transmitting commands are single, block, repetitive, 
and timed-repetitive. Single command is the transmission of a single command word. 
Block command is a group of single commands represented by just one command 
number. A repetitive command is a single or block command that a ground station 
retransmits continuously until there is a command verification or a selected number of 
transmission attempts have been reached. The timed-repetitive command is the 
transmission of a block or single command for a given period of time (it is the least 


frequently used method). (Ref. 6] 


4. Ground System Basic Elements 
The ground system of a TT&C architecture can be described using eight elements: 


e Antenna System 


This includes a single antenna and mount, its associated actuators, 
consoles and servo circuitry that control the antenna, the feeds and 
transmission lines that carry the radio frequency (RF) signal to and from 
the equipment. [Ref. 5] 
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e Autotracking 


The use of a received space vehicle signal to steer the antenna. [Ref. 5] 


® Receive RF Equipment 


The equipment required to accept the downlink carrier frequency from the 
antenna system, down-convert it to intermediate frequency, and 
demodulate it to a base band signal for the equipment devoted to mission 
data recovery and TT&C. [Ref. 5] 


¢ Transmit RF Equipment 


The equipment required to accept tracking and command signals from the 
ground systems TT &C component and modulate them onto the RF uplink 
which it also generates. [Ref. 5] 


® Mission Data Recovery Equipment 


Equipment required to condition the mission data before relaying it to data 
users and ground system components. [Ref. 5] 


® Data User Interface 


Equipment required to connect the mission data recovery equipment and 
the data user. [Ref. 5] 


e TT&C Equipment 


Equipment required to condition and distribute received telemetry and 
tracking signals. Also it electrically formats, authenticates, and time-tags 
transmitted command and tracking signals. [Ref. 5] 


® Station Control Center 


This center is given the responsibility to control the configuration of, and 
the interconnections between, the ground station components. Operating 
under instructions from the ground system's mission control center, it 
keeps the ground station configured to support mission operations. [Ref. 
5] 
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® Mission Control Center 


This center plans and operates the entire space mission, including the 
configuration and scheduling of resources for both space and ground 
system. It computes and issues information needed by ground system 
elements and data users, such as data on the spacecraft's orbit, ground 
station pass times, and antenna pointing angles. [Ref. 5] 


C. IDENTIFICATION OF TT&C FUNCTIONS 


1. Introduction 


This section will develop a common description of TT&C related functions and 
illustrate their interrelationship within the TT&C process. To accomplish this, a three 
level approach is used. This approach classifies a function into one of three levels: 
Primary, Secondary, and Sub-Function. To explicate this approach, the DOD descriptive 
language IDEF, is used. In particular, Design/IDEF (version 3.5) developed by Meta 
software corporation was the tool selected. It will be noted that in this chapter only the 
analysis and design diagrams for the higher level activities will appear. The complete set 
of IDEF, illustrations developed for this architecture, with all inputs and outputs included 
is located in Appendix A. IDEF, requires the user to define the functions associated 
Input, Output, Control, and Mechanisms. These four elements will be highlighted in the 
following sub-sections; and a complete definition of the elements is contained in 


Appendix B. 


2. Primary Functions and Associated Secondary Functions 


The upper levels of the IDEF, diagrams provide a method to display the importance 
of certain key functions which the authors have identified as primary functions required 
to conduct TT&C. Corresponding secondary functions will be identified but later 


discussed in the following section. 
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Figure 1, The TT&C Process, illustrates the Top level of the TT&C process. This 
diagram shows all the inputs, outputs, controls, and mechanisms associated with the top 
level. The essential components, both required for and result of the process, were 
identified and placed on the top level diagram indicating their contribution. 

At the top of the figure, the four major controlling factors are listed: Space Vehicle 
Requirements, Mission Need Statement, Space Policy, and Support Requirements. These 
controls tend to highlight the long term requirements pertaining to the overall role or 
mission of a space vehicle and ensuring its health over time. They are used to establish 
doctrine, policies, and standard operating procedures (SOP) necessary for the proper 
utilization of any space asset. 

Located on the left are the inputs to the TT&C process: User Tasking, User 
Feedback, and Space Vehicle (SV) Requirements. Basically, inputs act as the initial 
starting mechanism to the process. They are a response to a need that must be fulfilled in 
the short term unlike controls which involve long term concerns. The user places the 
process into motion by providing a task to a controlling authority of a military space asset 
or in stating recommendations concerning outcomes of previous tasking. These methods 
are known as User Tasking and User Feedback, respectfully. It is important to note that 
Space Vehicle Requirements acts as both a control and an input. During the design of a 
space vehicle, specific handling methods and limitations are incorporated to provide as 
long a life as possible. However, as a system reacts to its environment, unforeseen 
abnormalities tend to occur and must be corrected or compensated for in the short term to 
avoid damage or loss of the space vehicle. | 

Listed at the bottom of the diagram are the three primary resources which aid in 
supporting the process of conducting TT&C. Facilities provide the structures which 
house the Computer Hardware & Software elements and their operators and maintainers 


known as Personnel. 
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Figure 2, Conduct TT&C Primary Functions 
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The desired results of this process are Evaluation / Status reports concerning the 
system and mission data requested by the user which initiates User Feedback. This is 
simply a broad look at the TT&C process. Further understanding of the process is 
provided within the next level diagrams. 

Figure 2, Conduct TT&C Primary Functions, illustrates the four primary functions 
required to conducting TT&C. They are characterized as the following: Perform 
Planning, Perform Support & Networking, Conduct Operations, and Conduct System 
Analysis. The IDEF, diagram illustrates the interrelationship of those four key functions. 
It is able to accomplish this by highlighting the dominating outputs of each function and 
mapping them as inputs to the others. 

An overview of the process shows initially that it begins with a planning stage. 
User tasking, in conjunction with available assets, SV requirements, governing policies, 
and other initial requests, allows the creation of an operational plan. This plan becomes 
essential in identifying and ensuring the proper configuration of resources and prioritizing 
of assigned missions. Throughout the process a continuous planning cycle is achieved by 
maintaining feedback loops between the functions which allows for modification and 
improvement to the original operations plan. 

The next stage, Perform Support and Networking, involves coordination of all 
required assets, which includes items such as remote antenna sites, computer 
workstations and their operators. The proper execution of the plan is assured by 
developing a specific resource configuration which will be utilized by the personnel 
involved in the conducting of actual operations. Feedback to the planning stage is in the 
form of listing available assets and stating needs for continued support capability such as 
personnel training and scheduling down time for required maintenance. 

The main purpose outlined in this process is to produce results for the user. These 
results are derived from the third stage, Conduct Operations, in the forms of user 
requested mission data to support military operations or reports to superiors which detail 


current status and efficiency of the TT&C facility. 


21 








od Saanian BUTUUPTY WWOpIag 


“TILL Iv ‘dQON 


{AUUOSI3q 


LW 
( 








dj 
assy sIGeileAy 





cl 


— | syoday jeuiayul 


vl 
SUON SY 
papuswwo3aa 





0 








UR Id 
suoieiado 





l¥ 
suonmppy [ao 





gl 
apraodg 





UOREIJPOW 
ainpauss 





spgaNn Loddns 





UO 1yeI NS IJUOIIY 

peojkeg 
UNO Jag 
@® awauinb3sy AS 









Ueid uOgesnbyucIey al 


















ueig JuaWwAD\dag Il¥ 
ee ae qua uhojdeq 
aaJo7 aaeds 
aptaodg 

os __ fay) 

40) LS Se 
Adliog a2eds WaWs}e]S Pah UO|ss|W sjuawauinbay ajiued aveds Burse i Jason 
fener 
Bet Ye ee eed Livad] | vidiiagie Porc ior 

‘IXaLNOo{ ALVG wadvaa ONIYOM | x | JOHIEAA 8 eDMUA SLT OHL AV ‘LV aasn 


Figure 3, Perform Planning 





22 








Outputs, that remain internal to the process at this level, were non-immediate 
recommended actions which would be placed in the operations plan to ensure the 
continued health of the space vehicle and status of both the SV and ground facility 
required for system evaluation. 

It is important to note that the final stage is not simply delivery of mission data to 
the user. There exists an internal method of analyzing the complete process through the 
use of reports, evaluations, and recommendations which allows for system improvements. 
Conduct System Analysis is the last of the primary functions detailed in the IDEF, 
diagram. It includes internal feedback to the other functions in an effort to achieve the 
most efficient mode of operation. Recommended Actions are outputs of this stage which 
attempt to rectify abnormalities identified in the system. 

In the concluding part of this section, the next level of each primary function is 
diagrammed and discussed. The functions which support any given primary function are 
known as secondary functions. These functions are listed in the following sub-sections 
with their associated primary function; however, the secondary function definitions are all 


located in Section C.3 of this chapter. 


a. Perform Planning 


This primary function involves the correlation of multiple inputs, identifies 
potential options and presents a final strategy which is then reintroduced into the system 
and accomplished over a period of time. The IDEF, diagram for this function appears in 


Figure 3, Perform Planning. 
ASSOCIATED SECONDARY FUNCTIONS 


¢ Provide Space Force Deployment 
¢ Perform Payload Reconfiguration 
® Provide Schedule Addition 


¢ Perform Operations Planning 
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These next level functions were determined to be the major parts of the TT&C 
Planning process. As stated earlier, the goal of this primary function was the creation of 
the Operations Plan. This plan is identified as a master schedule which outlines what 
needs to be done to a SV, how it will be done, and who, with what resources, will do it. 
To develop this plan, a series of minor plans are formulated and merged along with 
inputed recommended actions. The driving force behind prioritizing mission related 
actions is user tasking and SV requirements. Perform Operations Planning accomplishes 
this task by acting as the main merging function. It is here that the routine schedule for 
SV monitoring and mission tasking occurs based on support needs, available assets and 
standard operating procedures. A continual loop for changes to the plan are provided for 
with the input, Schedule Modification. Based on needs which must be acted upon in the 
short term, Provide Schedule Additions becomes the avenue for the user and others 
within the system to work into the schedule critical modifications. Finally, it was 
determined that the functions Provide Space Force Deployment and Perform Payload 
Reconfiguration were aspects of the TT&C process that required special handling above 
what would normally be known as routine activities. Their output would be the drafting 
of a deployment plan and reconfiguration plan, respectfully, which would be merged with 
the routine plan. Once again, this allows for the creation of a prioritized schedule known 
as the Operations Plan which directly impacts both conducting operations, and support 


and networking arrangements. 


b. Perform Support and Networking Functions 


Once the Operations Plan has been formulated, it is the primary task of the 
Perform Support and Networking function to ensure availability of required assets and 
resources. The primary output is the establishment of a Resource Configuration. The 
ability to assign control and authority of individual assets provides the foundation 
necessary to link all other functions to their required resources in an effort to support all 
aspects of a TT&C system. The supporting secondary functions are listed below and their 


interrelationship is displayed in Figure 4, Perform Support and Networking. 
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ASSOCIATED SECONDARY FUNCTIONS 


Conduct Training 


Conduct Logistics 


Conduct Maintenance 


@ Allocate Resources 


The operations plan is seen as the input which schedules certain non-operational 
activities to commence. This plan is further supported by internal reports which outline 
additional concerns surrounding those activities. These activities include scheduling 
simulator time for operators or allowing them time to attend training courses to provide 
improved performance. This involves the function known as Conduct Training. As these 
training opportunities are conducted, feedback concerning the outcome of these activities 
begins with the delivery of personnel qualification status updates. Qualified personnel 
are counted on the available assets report while deficiencies are highlighted in the support 
needs report. Both of these reports eventually arrive back at the planning stage to start 
the process all over again. 

Conduct Maintenance works along the same lines as that of the function, 
Conduct Training. The main difference is the scheduling of hardware and software 
components vice personnel activities. It is important to provide down time for 
maintenance work, but doing so removes an asset from use for a period of time. 

Maintenance work ensures the continued health of a given TT&C resource and 
as such must be scheduled for by the planners. The feedback to the planners begins with 
the maintenance status report which is sent to be added to both the support needs and 
available assets reports. 

The logistic schedule is the result of the function, Conduct Logistics. After 
reviewing inputs to the function, non-flight essential support needs are identified and a 
plan of action is drafted. This logistic schedule states activities that are occurring to 


assure delivery of determined support needs. 
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Figure 4, Perform Support and Networking 
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The final stage for merging all the above information is called Allocate 
Resources. Controlled by standardized support requirements, this function takes all 
inputs and interprets resource needs. Conflicts in resource assignment are handled 
through the prioritization of missions established in the operations plan. As previously 
stated, the configuration of resources is the focus of this primary function. This output 
greatly affects how smoothly operations will be conducted. 

Although not shown in the diagram, the primary function, Perform Support and 
Networking, provides the additional foundation for Communication Connectivity and 
Security. Communication Connectivity is the ability to provide secure primary and 
alternative communication links that would connect control centers, remote ground 
facilities, and external users / facilities. Connectivity would be comprised of the 
following: LAN / WANs, data link terminals, commercial services, military 
communication satellite, and domestic commercial communication satellites. Security is 
the ability to protect against those threats identified in DOD Command & Control 
Warfare (C2W) / Information Warfare (IW) assessment documents. Security capabilities 
shall encompass the following: system, personnel, information, physical, 


communications, emanations, and computer systems. 


c. Conduct Operations 


| The Conduct Operations function is responsible for the execution of the 
operations plan. The associated secondary functions are listed below and a graphical 


representation is given in Figure 5, Conduct Operations. 


ASSOCIATED SECONDARY FUNCTIONS 


Provide Space Vehicle Position and Orientation Management 


© Perform Constellation Management 


Execute TT&C 


® Disseminate Mission Data 
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Figure 5, Conduct Operations 
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If the planning stage were known as the brains of the TT&C process, then the 
operations stage is its heart. It is here that the system answers the user's tasking and 
provides the desired results. It begins with the function, Execute TT&C, where signals 
sent from participating space vehicles are received. These signals are processed to reveal 
the information that they are carrying. The diagram labels the signals as either a contact 
track or telemetry data. Contact tracks provide information on tracking data which is 
utilized in determining a SV position and orientation. Whereas, telemetry data delivers 
information pertaining to the SV's health status and associated mission related data. At a 
later point, the health status, known as SV System Status, along with Ground System 
Status gathered from within the process of executing TT&C, becomes an input for 
analysis of the system's performance. Mission data is sent to the resources capable of 
disseminating it to the user in a form usable by that user. 

Commanding a space vehicle is an ability critical to executing TT&C. A 
command to reorient a SV begins with a requirement for increased accuracy in 
determining the position of the SV. Position and orientation management allows for 
further precision of the tracking data. If the SV 1s associated with additional SV's, 
constellation management will provide any adjustment recommendations to ensure the 
integrity of that constellation. Time sensitive actions are sent directly to the function, 
Execute TT&C, to be processed into commands. These actions normally involve 
preventing or correcting an abnormality which could damage the SV. Non-immediate 
recommended actions are held until they can be incorporated into the operations plan. 
The plan contains a list of commands that will be transmitted to the SV at a specified 
time. This list and any immediate recommended actions are converted into appropriate 
command language and transmitted to the SV as scheduled. 

Finally, the figure shows that internal reports are merged and prepared in the 
function, Disseminate Mission Data. It is through this route that users and other 
governing authorities receive requested reports on the status of the TT&C process and 


results of evaluation analysis. 
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d. Conduct System Analysis 

Conduct System Analysis is the last of the four primary functions, and through 
its output, a continual feedback loop within the TT&C process is established. This 
feedback, in the form of internal reports and recommended actions to correct for 
abnormalities, allows the controlling agency to observe its performance, identify 
deficiencies and provide an avenue for improvement and growth. This function will 
present current as well as time trended system performance for evaluation by outside 
sources. Figure 6, Conduct System Analysis, illustrates how the five secondary functions, 


listed below, enable the process to acquire this detailed look at itself. 


ASSOCIATED SECONDARY FUNCTIONS 





® Determine Ground System Status 

® Provide Ground Evaluation 

e Determine SV System Status 

© Provide Payload / Platform Evaluation 


e¢ Perform System Analysis 


The analysis is conducted in three stages: a look at the ground segment, a 
separate look at the SV segment, and combined look to provide an overall evaluation of 
system performance. Analysis begins with current status reports being delivered by 
operations concerning both the ground and SV segments. Additional feedback from the 
user is utilized to evaluate the quality of the product produced by the space vehicle. The 
secondary functions dealing with determining ground and SV systems status receives 
their respected inputs and derives a health and status condition on each segment. Any 
abnormalities requiring immediate corrective response is accompanied with the activation 


of an alarm along with being highlighted on the health and status report. 
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It is the functions which provide evaluations of the segments that actively seek 
out the cause of a problem and determine the degradation of a system. The findings are 
included in the performance reports and sent for final analysis. 

Perform System Analysis is the final function which merges all the information 
inputed and formulates the recommended actions necessary to rectify any abnormality. It 
takes a complete look at the total process to ensure that actions taken on one particular 
system does not adversely affect other systems. The implementation of internal reports 
grants the other primary functions an opportunity to monitor their overall effectiveness 
based on time trended performance evaluations. It is these evaluations that create a loop 


within the TT&C process allowing feedback between all activities. 


3. Secondary Functions and Associated Sub-Functions 


The following section, along with the data dictionary found in Appendix B, 
provides further insight into the process of TT&C. The secondary functions, the 
immediate level which supports the primary functions, are listed in alphabetical order. 
Their definitions will include redefining essential inputs, outputs, controls and resources. 
Sub-functions are simply the next level in the process chain. They directly support a 
specific secondary function and will be listed immediately following the definition of that 
function. It is important to note that some secondary functions listed in this text are not 
associated with any sub-functions. The authors determined that certain functions required 
further break down in order to better aid the decision maker's understanding of the TT&C 
process. The remaining functions, as well as the sub-functions, were basically self 


evident and no further insight was required. 


a. Allocate Resources 

This is the ability to interpret SV support requirements into near term 
equipment utilization schedules for all elements of satellite control. The key inputs being 
an operations plan, internal reports, a logistic schedule, maintenance asset status, and 


personnel qualification status. Key outputs are resource configuration, support needs, and 
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available assets. A single controlling factor is identified as support requirements. Key 


resources are personnel and computer hardware & software. 


ASSOCIATED SUB-FUNCTIONS 





e Perform Scheduling of Operations per Operator 





e Perform Network Scheduling 


e Establish Pre-Designated Network Configurations 


b. Conduct Logistics 


This provides the capability of integrating non-flight essential supporting 
elements into an efficient logistic plan. Key inputs are the operations plan and internal 
reports such as a logistic request. The output being the logistic schedule. As always with 


logistics, the key resource is personnel required to take action. 


c. Conduct Maintenance 


This is the ability to perform routine, periodic, and unscheduled / time critical 
maintenance support on ground segment and related facilities. Associated inputs to this 
function are the operations plan and internal reports. The key output is the maintenance 
asset status report. The key resource to this secondary function is the personnel required 


to perform maintenance tasking. 


ASSOCIATED SUB-FUNCTIONS 


® Provide Maintenance Personnel 


® Perform Routine / Periodic Maintenance 


¢ Perform Logistic Support 
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d. Conduct Training 


This is the ability to provide realistic training by utilizing classroom, on-the-job, 
and simulator environments. The key inputs associated with this function are the 
operations plan and internal reports. The output from this function will be a personnel 
qualification status report. The key resource is personnel, specifically instructors when 


dealing with training evolutions. 


ASSOCIATED SUB-FUNCTIONS 


® Provide Maintenance Personnel 
® Perform Routine / Periodic Maintenance 


e Perform Logistic Support 


e. Determine Ground System Status 


This is the method to detect and isolate problems in order to determine ground 
segment current status. The key input to this function is the Ground Segment Status. 
Outputs to this function are Alarms and Ground Segment Health and Status. Resources 


affecting this function are the Computer Hardware and Software. 


f. Determine SV System Status 


This is an ability to provide a method to detect and isolate problems in order to 
determine the space vehicle system's current status. The key inputs to this function are 
SV System Status and User Feedback. Outputs include Alarms and SV Health & Status. 
The single control affecting this function is SV Requirements. The two resources 


involved are Personnel and Computer Hardware & Software. 
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g. Disseminate Mission Data and Other Information 


This allows for the capability of distributing processed and unprocessed data 
from the satellite control node to the C2 node (user). Additional information required by 
the user outside of mission related data would also be disseminated. Key inputs to this 
function are Mission Data (Processed and Unprocessed) and Internal Reports. The 
associated outputs are Distributed Mission Data (Processed and Unprocessed) and 


Evaluation / Status Reports. 


ASSOCIATED SUB-FUNCTIONS 


® Disseminate Processed Data 
e Ability to Disseminate Unprocessed Mission Data 


@ Disseminate Evaluation / Status Reports 


h. Execute TT&C 


This function maintains the systems ability to receive telemetry data, gather and 
process azimuth and elevation data, as well as other pertinent navigation information. 
Also included in the function is the transmitting of commands necessary to control both 
payload and maintain health and status of the platform. Supporting functions include; 
receive data, collect and process pointing data, determine range and range rate, transmit 
payload commands, maintain health and status, provide antenna connectivity, concurrent 
events, and establish timing accuracy. Key inputs to this function are the Operation Plan, 
Immediate Recommended Actions, Recommended Action, Telemetry Data, Contact Data, 
and Resource Configuration. Outputs associated with this function are Commands, SV 
System Status, and Ground System Status. Resources belonging with this function are 


Computer Hardware & Software, Facilities, and Personnel. 
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ASSOCIATED SUB-FUNCTIONS 


¢ Determine Range 


® Collect and Process Pointing Data 


® Calculate Azimuth and Elevation 


e Establish Timing 


® Receive Data & Command Verification 


Data and Control Commands 


i. Perform Constellation Management 


This is the ability to determine, predict, and adjust as necessary the SV orbital 
parameters in order to maintain constellation integrity. The key input associated with this 
function is Positioning Data. The resultant output being Constellation Adjustment. The 


associated control with this function is Space Vehicle Requirements. 


j. Perform Operations Planning 


This is the ability to perform all planning functions to include; mission planning, 
contact objectives, command generating, contingency, and time sensitive planning. 
Inputs involved are Deployment Plan, User Tasking, SV Requirements, Schedule 
Modification, Support Needs, Reconfiguration Plan, Recommended Actions, Internal 
Reports, and Available Assets. The key output to this function is the Operations Plan. 
Controls affecting this function are Space Policy, and the Mission Need Statements. A 


common resource associated with this function 1s Personnel. 
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ASSOCIATED SUB-FUNCTIONS 


¢ Define Contact Objectives 
® Perform Command Generation 


® Perform mission Planning 


k. Perform Payload Reconfiguration 


This is the ability to provide a planning responsiveness to users that involves 
possible changes to the control of the platform or payload systems. The key inputs 
associated with this function are the User Tasking and SV Requirements. The associated 
output being the Reconfiguration Plan. Controls related to this function are SV 


Requirements and Mission Need Statements. 


1. Perform System Analysis 


This is the ability to evaluate overall system performance. It would include 
conducting long term trend analysis and capacity management evaluation. Key input 
parameters associated with this function are the SV Performance Report and the Ground 
Performance Report. Outputs from this function are Internal Reports and Recommended 
Actions. Controls affecting this function are the Antenna Network, Communication 
Capacity, Satellite Operations Center Requirements, and System Requirements. 
Resources belonging to this function are the Processor, Software, Capacity Models, and 


Trending. 
ASSOCIATED SUB-FUNCTIONS 


¢ Evaluation of Overall System Performance 


¢ Conduct Long Term Tend Analysis 
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e Evaluate System Capacity 


m. Provide Ground Evaluation 


This provides for the ability to quickly assess, isolate, and correct ground system 
failures. Inputs belonging to this function are Alarms and Ground Segment Health and 
Status. Outputs associated are the Ground Performance Report. Resources falling under 


this function are Personnel and Computer Hardware & Software. 


ASSOCIATED SUB-FUNCTIONS 
® Conduct Isolation of Ground System Problem 
e Notify Operator 
e Recommend Corrective Action 


n. Provide Payload / Platform Evaluation 


The function maintains the ability to assess, verify, and conduct detailed 
performance analysis either during or after a SV contact. Key inputs to this function are 
the SV Health & Status and the Alarms. The output is the SV Performance Report. The 
key governing control to this function is SV Requirements. Resources affecting this 


function are the Personnel and Computer & Hardware & Software. 


ASSOCIATED SUB-FUNCTIONS 


© Conduct Isolation of System Problem 
® Notify Operator 


© Recommend Corrective or Safing Action 
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® Verify Mission Events 


0. Provide Space Force Deployment 


This function provides the planning for all aspects of Space Force Deployment. 
Activities involved include pre-launch preparations, launch support, early orbit checkout, 


and positioning of the SV. 


p. Provide Space Vehicle Position and Orientation Management 


This function provides the ability to determine, predict, and adjust orbital 
parameters of the SV within specified limits. The input is the Tracking Data. The 
outputs includes Position Data, Immediate Recommended Action, and 


Non-Recommended Action. The control on this function is SV Requirements. 


ASSOCIATED SUB-FUNCTIONS 


® Determine Space Vehicle Position and Orientation 
® Predict Position and Orientation 


e Adjust Orbital Parameters 


q. Provide Schedule Additions 


This function provides a responsive capability to the SV system user (either 
external or internal ) to accomplish non - nominal or emergency support requirements 
(mission tasking). This entails formulating schedule options and resolving possible 
schedule conflicts. Key inputs to this function are User Tasking, Non-Immediate 
Recommended Action, and the Operations Plan. The output to this function is the 
Schedule Modification. Controls acting on this function are the Mission Need Statements 


and Space Policy. Personnel is the essential resource involved with this function. 
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ASSOCIATED SUB-FUNCTIONS 





® Determine Schedule Options 
® Resolve Schedule Conflictions 


® Execution of Schedule Addition 


D. SUMMARY 


This chapter presented a generic look at the TT&C process by identifying essential 
functions and their interrelationship amongst each other. This was achieved by 
graphically presenting the four primary functions, associated secondary and sub-functions 
in a DOD accepted activity modeling technique. By understanding the process, the first 
step toward providing a comprehensive guideline to aid the decision maker is established. 
This guidance would focus the decision maker's areas of concern surrounding future 
proposed TT&C candidate architectures. 

However, to ensure a completely informed decision, it will be necessary to examine 
present architectures and develop a method to objectively rank them. This will be the 


intentions of the following two chapters. 
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It. CURRENT TT&C METHODS AND TRENDS 


A. INTRODUCTION 


To properly make good judgmental choices for development of future TT&C 
architectures, it is essential that the decision maker have a well defined description of the 
current TT&C architectures. Currently, there exist a multitude of TT&C architectures 
that could be used to formulate this baseline. The options for discussion range from both 
national and international military and/or commercial oriented systems. This chapter will 
limit itself in an attempt to provide an in-depth descriptive look at three well known 


domestic options. 


e = Air Force Satellite Control Network (AFSCN) 
© Mission Control Center (MCC), Johnson Space Center 


° §©Naval Satellite Operations Center (NAVSOC) 


These options were chosen on the basis of available material / resources and their 
non -proprietary nature. The options represent varying and distinct aspects to TT&C 
development. Their approaches to TT&C range from utilizing historically proven 
processes to the development and integration of advanced control / communication 


techniques. 


B. AIR FORCE SATELLITE CONTROL NETWORK (AFSCN) 


1. History 


The AFSCN capability was established in 1959 in response to worldwide classified 
programs. Growing to match expanding user requirements, the AFSCN went from 
controlling just three satellites to presently 90 plus satellites projected for the end of 
1997. As a result of its ability to validate technology, the Space Ground Link System 
(SGLS) established by the AFSCN has become the accepted DOD standard. 
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2. Command Structure 


The AFSCN is under operational control of the Air Force Space Command 
(AFSPACECOM), headquartered at Peterson Air Force Base (AFB). The 50th Space 
Wing, headquartered at Falcon AFB, is responsible for the operation and management of 


the AFSCN. The 50th Space Wing Organizational Structure is shown in Figure 7. 


3. Baseline Resources 


a. Remote Sites and Antenna Capability 


There are sixteen common-user TT&C remote tracking stations spread out over 
nine geographical locations shown in Table 1. Three Remote Tracking Stations, Mahe 
Indian Ocean (IOS), Falcon Air Force Base (FAFB) Colorado Springs (CTS), and Diego 
Garcia (DGS) are single sided, that is to say, they have only one TT&C antenna. Five of 
the remaining six sites, Manchester New Hampshire (NHS), Kaena Point, Oahu Hawaii 
(HTS), Vandenberg AFB (VTS), Oakhanger England (TCS), and Guam (GTS) are dual 
sided. Lastly, Thule Greenland (TTS) is triple-sided. Knowing that one side can provide 
services to one Space Vehicle (SV) at a time results in the previously stated sixteen 
common-user TT&C stations. An "S" band space-ground interface is utilized while 
primary and alternate AFSCN communications are maintained to the control centers. 
[Ref. 7] 

The AFSCN Common-User Non TT&C facilities are Camp Parks 
Communication Annex (CPCA), located at Pleasanton CA; the Eastern Vehicle Checkout 
Facility (EVCF), at Cape Canaveral FL; and multiple mobile systems can perform TT&C 
functions with one SV at a time. 

The dedicated control centers coordinate with the Operational Control Nodes 
(OCNs), Falcon Air Force Base and Onizuka AFB, for the scheduling and allocation of 
resources. An example would be Milstar Operations Center (MOC) at Falcon Air Force 
Base, Global Positioning System (GPS) Master Control Station (MCS) at Falcon Air 
Force Base, and Naval Space Operations Center dedicated to the FLTSATCOM program. 
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Figure 7, 50th Space Wing Organization, From Ref. 8 
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There are five non TT&C Monitor Stations (MS) all of which are dedicated to 
GPS. Of note, all five MSs have "L" band omni antennas used for tracking and 


monitoring the GPS satellites (i.e.: ephemera data collection). 


racking Station Number of Antennas 


a 2 Space-Ground Link 
System (SGLS) 

Guam (GTS) 

Indian Ocean (lOS) 


Table 1. AFSCN Common User TT&C Tracking Stations 





—_j 




















b. Personnel 
There are approximately 1200 personnel assigned to the AFSPACECOM. With 
the responsibility of over 90 plus satellites to control, this manpower level allows for a 


personnel to satellite payload ratio of 8:1. 


c. Supporting Facilities 
Supporting facilities for the AFSCN is provided within the command structure 


itself. These supporting facilities include some of the following: 


© 50th Logistics Group - manages logistic support activities for the ground 


control systems. 


® 50th Support Group - maintains and operates Falcon Air Force Base which 


would include physical security, and utilities & environmental support. 
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® 750th Space Group - located at Onizuka AFB CA, provides backup for TT&C 
support to AFSCN users. 


4. Operational Methodology 


The AFSCN is considered to be a centralized network revolving around the primary 
and secondary Mission Control Complex (MCC) located at either Falcon AFB or 
Onazuka AFB respectively. The operating methodology for the AFSCN is known as the 
Command and Control System (CCS). The CCS takes advantage of a centralized 
command & control] structure which provides for user dedicated data processing. 
Inherent to the CCS system the Remote Tracking Stations (RTS) utilize the Remote 
Control and Status Equipment (RCSE) which allows the RTS to act as a geographic 
disperse relay site. This enables the RTS to directly relay the entire received telemetry 
stream back to a CCS- compatible MCC or act as a relay for SV commands from the CCS 
MCC to the SV. Because of centralized location of the main processors, all processing 
and analysis is conducted at the MCC site. As a result, real time access to the entire 
telemetry (TLM) stream is possible. The CCS architecture consists of the following 


major hardware items: 


© Main Processors - Each MCC contains two main processors referred to as the 
Contact Support Processor (CSP) and the Planning and Evaluation Processor 


(PEP). [Ref. 9] 


e Processor Peripherals - Storage peripherals include Direct Access Storage 
Devices (DASDs) and magnetic tape units. Display peripherals include 


interactive display terminals and hardcopy printers. [Ref. 9] 


® Classified Interface Unit (CIU) - This unit receives and transfers data from the 
Command Contact Support Equipment Group (CSEG) and Isolation Review 
Unit (RU) to the processor. Data includes pointing commands, RTS 


configuration directives, and SV commands. [Ref. 9] 
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® Unclassified Interface Unit (UIU) - This unit receives and transfers data to and 
from the CIU via the IRU and or Command CSEG. Data includes tracking and 
RTS status, RCSE ground directives, and encrypted SV commands. [Ref. 9] 


e Isolation Review Unit - Receives data being transferred from the CIU to the 
UIU and returns data that does not pass security reviews back to the CIU. [Ref. 
2] 


® Telemetry Interface Unit (TIU) - The TIU receives data from the telemetry 
CSEG and transfers the data to the CSP. [Ref. 9] 


© Telemetry CSEG - The telemetry CSEG preprocesses, synchronizes, and 
decrypts telemetry data. [Ref. 9] 


® Command CSEG - The CSEG encrypts command data originating in the CSP 
and decrypts command echo data. [Ref. 9] 


A descriptive diagram can be found below in Figure 8, AFSCN Satellite Control 


Architecture. 


g 
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External sites 


- Mission data 
processing 


- Osites 
- Partially automated 


- Operations: 
-- LEO 
-- Normal ops 
-- Anomaly resolution 





Figure 8, AFSCN Satellite Control Architecture, From Ref. 10 
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5. Strengths and Capabilities 
The AFSCN architecture strengths lie in the following areas: 


® Establishment of a worldwide antenna network providing global coverage 
¢ Support launch and space force deployment 


¢ Current infrastructure allows for the management of a large volume of space 


vehicles 


® On - orbit commanding / support of SVs 
C. NAVAL SATELLITE OPERATIONS CENTER (NAVSOC) 


1. History 


With the development of the TRANSIT satellite system to meet Fleet Navigation 
Requirements, the Naval Satellite Control Network (NSCN) became operational in 
1962. The NSCN currently provides support for less then thirty satellites. With only three 
remote sites and one SGLS antenna per site, the NSCN is acclaimed for its use of open 
and distributed architecture strategies and Commercial Off the Shelf (COTS) 


implementation. 


2. Command Structure 


The Naval Satellite Operations Center (NAVSOC), located at Point Mugu CA, 
provides the command and control of satellite systems assigned by the Naval Space 
Command (NAVSPACECOM), headquartered at Dahlgren, VA. The NAVSOC operates 
and maintains the NSCN which comprises all of the satellite TT&C ground-based 
hardware and software. A descriptive view of the organization is provided in Figure 9, 


NAVSOC Organization. 
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Figure 9, NAVSOC Organization, From Ref. 11 


3. Baseline Resources 


a. Remote Sites and Antenna Capability 


The NSCN remote sites are located in Table 2, NSCN Remote Sites and 
Capabilities. The basic configuration of each site is similar except that the Laguna Peak 
and Detachment Alpha have the satellite-ground link system (SGLS) capability for 
satellite-to-ground communications. Currently there are no intentions to command from 
the Guam site due to the AFSCN Automated Remote Tracking Stations (ARTS) 
integration plan which calls for the sharing of AFSCN antenna sites assets on an 


as-required basis. [Ref. 11] 
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racking Station Number of Antennas 
rospect Harbor, Maine (DET ALPHA) 2 EHF, 1 SGLS, 1 VHF 


Rosemount, Minnesota (DET BRAVO) 3 VHF (Transit Only) 


AFB, Colorado Springs, CO (DET DELTA)|1 SGLS (Shared) 
aguna Peak, CA 1 SGLS & VHF, 1 VHF 


Guam (DET C) 1 SGLS, 1 EHF (UHF 
Follow-On) 


Table 2. NSCN Remote Sites and Capabilities 


| 





: 





















The architecture at each remote site comprises the following five subsystems: 
SGLS antenna subsystem, Doppler tracking subsystem, TT&C subsystem, Integrated 
Satellite Control System (ISCS) component subsystem, and Communication subsystem. 
The Communication Subsystem provides connectivity to non-NSCN systems, the other 


remote sites, and NAVSOC HQ. 


b. Personnel 


The NAVSPACECOM operates with a manpower level of approximately 180 
personnel and 17 operational satellites which results in a personnel to satellite ratio of 


approximatley 10:1. 


4. Operational Methodology 
The NAVSOC uses a distributed architecture globally (on a WAN basis) where all 


the components of hardware and software are standardized. The basic configuration of 
each site is similar, expect that the Laguna Peak and Detachment ALPHA remote sites 
have satellite-ground link system (SGLS) capability for  satellite-to-ground 
communications. The Integrated Satellite Control System (ISCS) is the methodology for 
performing NSCN satellite operations. The ISCS takes advantage of VAX hardware & 
software systems and uses the Naval Research Laboratory's (NRL) Common 
Environment for Testing (COMET) / Command and Telemetry System (CATS) software. 


The NAVSOC is currently progressing steadily toward an open architecture by utilizing 
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workstations and PCs. Eventually, the VAX systems will be replaced by a combination 
of PC type file servers and workstations. 


Through the implementation of ISCS each RIS can perform the following 
functions: 
e Evaluate telemetry and pass change only telemetry data to the communications 


subsystem for transmission to NAVSOC HQ 
e Evaluate telemetry limits and generate anomaly alerts. 
e Store telemetry data in designated formats. 


© Control antenna pointing based on satellite orbital elements received from the 


external system 
e Evaluates the ISCS software processes and generates anomaly alerts 
© Develops the schedules of all NSCN satellite contacts 
® Configures and controls ground station hardware components 


© Construct and store commands and command sequences and will initiate the 


command uplink to the satellite 


It should be noted that at the time of this writing, NAVSOC HQ does not have an 
antenna on site to provide SGLS communications due to the close proximity of the 
Laguna Peak site. However, the distributed architecture which NSCN employs allows 
the NAVSOC HQ the capability to control and collect data from or for any site within the 
NSCN. A descriptive diagram is shown in Figure 10, NAVSOC Satellite Control 
Architecture. The NSCN is comprised of the following major components: 

e Remote Site ISCS - Each site rane a Micro VAX computer which is 
connected to a Thinwire Ethernet Local Area Network (LAN). The LAN 
connects the Micro VAX to the telemetry and communications subsystems in 


the normal operational mode by using RS-232 interfaces. [Ref. 11] 
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HQ ISCS - This component contains redundant Micro VAX computers that 


perform the previously mentioned functions. [Ref. 11] 


ISCS Software - Menu driven command and control system operating on a 
Micro VAX computer. Basic software consist of VMS operating system, 
COMET / CATS, NRL developed software, and NAVSOC specific software. 
[Ref. 11] 


Communications - The communication component links the remote sites to 
NAVSOC HQ and other NSCN sites through a DECrouter. A dial up 
connection between remote sites and NAVSOC HQ provides a backup 


capability in degraded operational modes. [Ref. 11] 


Intersite Communications - Currently, all sites are linked via multiplexers on 
56 Kb/sec leased lines and a point-to-point packet network. The point-point 
packet network is implemented by the use of a commercial network 
architecture known as DECnet. The DECnet uses one channel out of 8 
possible. The remaining channels are used for passing real-time baseband data, 
voice & fax communications, antenna control, receiver, and bit synchronizer if 
the site computer is not available. The leased lines provide the data links 
among the three sites, allowing each site to communicate directly with 
NAVSOC HQ. At each site, the leased lines terminate in a modem, a KG-84, 
and a DECrouter hardware string. [Ref. 11] 
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Figure 10, NAVSOC Satellite Control Architecture, From Ref. 10 


5. Strengths and Capability 
The NSCN architecture exhibits the following strengths and capabilities: 
® COTS and International Standardization implementation throughout 


architecture 


® Distributed aspect of the system permits remote sites and HQ to act as backup 


allowing for multiple redundant systems in case of system degradation. 


© High level of automation allows for timely processing of Anomaly Analysis, 
Alarms, Corrective Action and Scheduling. This also enables a reduction in 


required personnel to accomplish these tasks. 


® Considerable potential for growth through the implementation of the Plug - In - 
Use concept allows access to other non NSCN assets. In addition, limited 
commanding capability for UFO Follow on and FLTSAT satellites has been 


achieved through this method. 
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D. MISSION CONTROL CENTER (MCC), JOHNSON SPACE CENTER 


1. History 


Since 1964, the Mission Control Center (MCC), located at Johnson Space Center 
Houston, has undergone a drastic metamorphosis which enabled it to meet current space 
vehicle mission requirements while meeting the present day economic demands. The 
MCC takes advantage of both COTS and the present day open architecture technology. 
Unlike the limited role of the NSCN, the MCC is required to handle a vast array of 
mission tasking; most importantly, that being the manned space flights and deep space 


programs. 


2. Command Structure 


The MCC is organized under the Director of Space Shuttle Operations Office, 
who's responsibilities include all aspects of NASA's highly visible operation, the Shuttle 
Transportation System (STS) Program. The Johnson Space Center (JSC), in which the 
MCC is an integrated part, and Kennedy Space Center (KSC) provide the required 
monitoring capabilities to ensure safe STS operations. The Director of Space Shuttle 
Operations delegates MCC operations and tasking to the manager of the Space Shuttle 
System and Operations Office. It is this office which is responsible for day to day 
manning of the flight director position. These individual flight directors personally 
oversee the operators of the MCC facility. Figure 11, MCC Command Structure, depicts 


a broad overview of the Space Shuttle Program Office. 
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Figure 11, MCC Command Structure, From Ref. 12 
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3. Baseline Resources 


a. Remote Sites and Antennas 


NASA receives data on S-Band, C-Band and KU-Band frequencies. Space 
Shuttle data and voice is downlinked via TDRSS Satellites or via ground stations. All 
TDRSS downlink is received at the NASA Johnson Space Center (JSC) through the 
White Sands Test Facility in New Mexico. All ground site downlink is received at 
NASA _ Johnson Space Center through either Sunnyvale CA, Goddard Space Flight 
Center (GSFC) or Kennedy Space Center (KSC). Appendix C identifies all the available 
ground sites utilized by NASA to receive Space Shuttle downlink. 


b. Personnel 


By reducing maintenance costs and increasing automation, the MCC has been 
able to reduce its staffing by 180 personnel while simultaneously growing overall 
operations capabilities to support Shuttle and future Space Station operation 
requirements. Currently, the MCC conducts operations with approximately 240 flight 
controllers on a three shift basis (80 per shift) and 75 ground controllers (25 per shift). 
The number of payload operators varies widely and is payload specific. Due to the nature 
and risk involved with manned space flight the MCC operates with a personnel to space 


vehicle ratio of approximately 315:1. 


4. Operational Methodology and Capabilities 


Operational systems include standard UNIX computer workstations using the DEC 
Alpha 500 platform for console operations, the IBM RS 6000 for front end processing 
with the Loral LI 550 telemetry processor for data operations. All workstations are 
interconnected on a Local Area Network (LAN) utilizing 125,000 ft of Fiber Optic Cable. 
The MCC boast having the worlds largest Fiber Optic Distributed Interface Network 


currently in use. 
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MCC Houston baselines the use of Commercial Off the Shelf (COTS) software 
and hardware where practical and estimates a reduction in lines of code from 4.6 million 
to 3 million by fiscal year 1999. Software standards for Terminal Communications 
Protocol / Internet Protocol (TCP/IP) communications protocol using the Fiber Data 
Distributed Interface (FDDI) network standard form the standards for the MCC 
communications backbone. Figure 12, MCC Satellite Control Architecture, provides a 


graphical representation of this architecture. 
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Figure 12, MCC Satellite Control Architecture, From Ref. 10 


5. Strengths 

The strengths of the MCC methodology stems from its fundamental underlying 
principle which is to build a world class Mission Control Center able to support multiple 
spaceflight programs while reducing long term operations and maintenance cost. In 
doing this the MCC has been able to construct a Mission Control Center that has the 
capability of providing rapid reconfiguration for the support of a variety of mission 


objectives while maximizing the use of COTS hardware and software. 
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E. TRENDS IN TT&C 


As stated above, the strengths of the current TT&C systems, supported by the 
documentation presented in Chapter I, emphasizes a capability of doing business 
differently. This necessity for change is being driven by budgetary constraints, reduction 
in available resources, and the ever changing technological environment. This forces 
organizations to incorporate the cutting edge of technology at the same time ensuring 
lower life cycle cost, simplified process, reduction in manpower, while maintaining the 
ability to meet future program requirements. In the authors opinion, utilizing this 
approach would allow a transition from the traditional 60's mainframe architecture to the 
less manpower intensive, highly automated, and more standardized approach that is 
becoming the signature of the 90's. 

The following trends were identified as being crucial in bringing current systems 


into the 90's: 


e Automation - The ability to perform a specific task without human interaction. 
Advantages of automation include freeing operator time which may result in a 
reduction in manpower and act as a safeguard minimizing human error in a 
specific task. Such tasks may include: SV pass scheduling, health monitoring, 


sending commands, and trend analysis. 


®¢ Commercial Off The Shelf (COTS) - An item of hardware or software that has 
been produced by a contractor and is available for general purchase. Benefits 
from COTS implementation allows for timely integration at a reduced cost 
while using current technology. Examples would include acquiring the use of 
off the shelf operating environments such as X-Windows and commercially 


available personal computers (PC) / workstations. 


® Distributed System - A decentralized system that is dispersed over an 
interconnected network. Benefits can include reduced cost as a result of not 


relying on centralized systems. This allows for a system which is multitasked, 
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the capability to achieve a robustness and redundancy level which is cost 
effective. An example would be allowing a single workstation at a specific site 
the ability to control not only on-site resources but that of shared resources 


located at remote sites. 


Open Architecture - A system that implements open specifications for 
interfaces, services, and supporting formats to enable properly engineered 
applications software: (a) to be ported with minimal changes across a wide 
range of systems, (b) to incorporate with other applications on local and remote 
systems, and (c) to interact with users in a style that facilitates user portability. 
The inherent benefit is that it allows future developing systems to use existing 
resources that can be shared or ported across an interconnected network. [Ref. 


4] 


Plug-In-Use - Until the establishment of a truly open architecture, Plug-In-Use 
will provide individuals access to another's resources. The advantage is a 

lower total cost because the development of a simple black box which allows a 
system to communicate to an initially non-compatible resource 1s less 
expensive then building a dedicated resource which would be compatible to the 
original system. An example of implementing this concept would be the 
option currently undertaken by NAVSOC that allows direct commanding of 


satellites through the use of the AFSCN established antenna network. 


Operator System Interface - The interaction between the operating system and 
operator which allows the operator the ability to disseminate the graphically 
represented data. The tendency now is towards simplified icon oriented graphic 
representations of system status's which allows for ease of use while cutting 


down on required console training requirements. 


Open System Interconnection (OSI) - The OSI model 1s the formulation of 


protocols used for data communications. It sets down a set of rules governing 
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communications between systems and defines the functional operation of the 
communications between user and network elements. A current example would 


be the Space Communications Protocol Standards (SCPS) which incorporates 





the OSI model and dictates the packaging sequence for communication 





between ground station and SV's. The use of SCPS would prevent the future 
development of satellites with proprietary communication methodology which 
would require additional expensive handling from current TT&C facilities. 


The resultant is reduced space operations costs and improved interoperability. 


The Decision maker needs to identify the above mentioned trends in a proposed 
architecture. If the above mentoned trends are implemented, two criteria must be 
determined; (1) ensure that the benefit of that trend is occurring and (2) recognize to what 
degree this trend is beneficial. 

In the following chapter, an assisting tool to the decision maker will be provided 
that will determine the degree of benefit of an overall proposed architecture. However, if 
the decision maker cannot identify the use of the trends, he / she must question the 
proposer of the architecture to identify what achieves the benefits of lower life cycle cost, 
manpower reduction, simplicity of process, and potential for growth. Once this has been 
answered and using the tool provided in Chapter IV, the decision maker will be able to 


determine if this is an acceptable risk. 
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IV. COMPARISON METHODOLOGY 


A. INTRODUCTION 


Recall that in Chapter I, it was stated that the primary goal was to provide a 
methodology capable of comparing current and future TT&C candidate architectures. By 
rating candidates, the attempt is to reduce O&M cost, improve efficiency while 
maintaining mission effectiveness, and solidify space vehicle control requirements. To 
accomplish this, the decision maker is specifically tasked to develop and apply a 
structured methodology to allow scoring and ranking of candidate architectures in terms 
of their operational merit and cost. It is important to note that operational merit is an 
objective rating of measures in both effectiveness and performance of individual 
architectures. Whereas, cost will primarily deal with the overall life cycle cost. The 
analytic hierarchy process (AHP) presents itself as an ideal method in achieving this 
primary goal. In addition to presenting the AHP process, the authors will provide an 


illustrated example that will execute the step by step procedures to aid in comprehension. 


1. The Analytic Hierarchy Process 


The analytic hierarchy process (AHP), developed by Thomas L. Saaty, is designed 
to solve complex problems involving multiple criteria. The process can be divided into 


the following steps: 


® Develop a hierarchy or graphical representation of the problem in terms of the 


overall goal, criteria, and the decision alternatives. 


¢ Develop a scaling methodology to enable an unweighted ranking of decision 


alternatives based on the criteria. 


¢ Establish significant relationships between multiple criteria's through a 


pairwise comparison methodology. 


¢ Calculate a final weighted ranking of the decision alternatives. 
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© Develop a cost hierarchy of each decision alternative. 


The above steps require the creation of working groups capable of identifying 
essential criteria which is quantifiable and pertinent to the overall goal. Once a list of 
criteria has been established, the working group must conduct two tasks. First, through 
an established scaling method, the group ranks each of the decision alternatives on each 
of the criteria. Finally, the relative importance between each individual criteria must be 
established. AHP recommends a pairwise comparison method to achieve this. Once the 
two tasks are completed, a mathematical procedure, known as synthesization, is used to 
develop a weighted ranking of decision alternatives. The last stage is to provide a cost 
hierarchy of each decision alternative. This cost hierarchy, along with the weighted 
ranking, will provide the decision maker with the decisive tools necessary to make an 


informed decision. [Ref. 13] 


B. DEVELOPMENT OF AN EQUAL WEIGHTED RANKING 


The initial step in AHP, as outlined above, is to provide a list of criteria’s to 
evaluate candidate architectures. From Chapters II and III, it was determined that the 
method to achieve this would be through identifying the primary performance / system 
drivers. These drivers would be essential in accomplishing all functions regarding 
planning, operations, system networking, and analysis. After thorough evaluation, eleven 
predominant drivers were revealed as likely candidates for a formation of a criteria list. It 
is important to note that through further research and analysis, additional drivers may be 
incorporated into this list. The following section will identify each individual system / 
performance driver and provide an associated scaling method. To rank a driver's ability 
to accomplish a specific function, a scale with values ranging from 0 to 3 was developed. 
These ranging values were associated with certain attributes capable of being included in 
the design of a candidate architecture. In some cases, a driver will not be presented with 


a complete 0 to 3 range for scaling values because of limiting attributes. An example can 
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be found below when discussing the driver standardization, the number zero was not 


used. 


1. TT&C System / Performance Drivers and Associated Scaling 


a. Capacity 


Capacity allows for the following: advanced capacity management planning 
ability; data rate easily variable to 25 Mbps based on user needs; and distributed open 
computing environments for easily expandable data processing capability. The rating 


scale for capacity is: 


® 1 implies the architecture exhibits only minimal growth capacity: meets one 


attribute or less 


e 2 implies the architecture exhibits only moderate growth capacity: meets two 


attributes 


e 3 implies the architecture exhibits a high growth capacity: meets all three 


attributes. 


b. Flexibility 


Flexibility is a driver that takes into account automated mission planning and or 
scheduling; easily expandable and reconfigurable communications capability; secure 
system configurations to allow for operations across all classification levels; and lastly 
distributed open computing environments to allow rapid operational changes. The rating 


scale for flexibility is: 


¢ 1 implies only minimally flexible: the architecture exhibits less than 


two of the above attributes 


¢ 2 implies moderately flexible: the architecture exhibits two or three of the 


above attributes 
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e 3 implies highly flexible: the architecture exhibits three or more of the above 


attributes. 


c. Information Timeliness 


This attribute is a measure of the architecture to satisfy all requirements levied 
on the space vehicles control system by the operational tasking, in a timely manner. The 
rating scale for Information Timeliness 1s: 

© 1 implies the architecture in question cannot satisfy all the requirements as 


based in the OPLAN and user requirements documentation 


e 2 implies the architecture in question can satisfy all requirements . 


d. Maturity 

Maturity is a measure of the state of development of the proposed architecture. 
If the architecture is or has been operating in a fully operational mode, then the candidate 
may be considered mature. If the candidate is based on technology under development 
and does not currently exist, then the architecture is in a conceptual state and cannot be 
considered mature. It is understandable that there will be some overlap between maturity 


and technical risk. The rating scale for maturity is: 


© 1 implies Conceptual: greater than 9 years to produce 
e 2 implies Research: 5 to 9 years to produce 


e 3 implies Development: 0 to 5 years to produce 


e. Relative Cost 


Relative cost is the cost to research the technical issues, develop, test and field 
the proposed TT&C architecture. The relative cost is not given in terms of cost versus 
effectiveness of the system, but use of the other eleven drivers will result in a higher 


ranking for a more cost effective system. The rating scale for relative cost 1S: 
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O implies Very High 


© 1 implies High 


2 implies Medium 


3 implies Low. 


f. Reliability 

That architecture which exhibits the following: expandable high data rate 
distributed workstations and broadened communications network; automated error 
detection and correction; and no mission impacting single point of failure. The rating 


scale for Reliability is: 


¢ 1 implies the architecture exhibits only minimal reliability or 


availability: meets one attribute or less 


e 2 implies the architecture exhibits only moderate reliability or 


availability: meets two of the attributes 


e 3 implies the architecture exhibits a high reliability or availability: meets all 


three attributes. 


g. Reporting & Tasking 

Reporting and tasking takes into account the following: distributed open 
computing environment with interface to existing external standard command and control 
systems for near real-time reporting and current status updates based on operational 
requirements; and distributed open computing environment with interface to external 
standard command and control system for near real time tasking response based on 


operational requirements. The rating scale for Report and Tasking is: 


¢ 1 implies the candidate architecture does not meet any of the attributes 


associated with reporting and tasking 
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e 2 implies the candidate architecture meets only one of the attributes associated 


with reporting and tasking 


e 3 implies the candidate architecture meets all of the attributes associated with 


reporting and tasking. 


h. Standardization 


The standardization of a TT&C architecture looks at the standard interfaces for 
all applications within the system and to all external users. The attribute also takes into 
account minimum need for dedicated resources or payload specific configurations. 
Finally, the driver takes into account the standard communications protocols and 
interfaces for voice, data, and video. 


The rating scale for standardization is: 


© 1 implies minimal use of standardization: meets one of the attributes 
e 2 implies moderate use of standardization practices: meets two of the attributes 


e 3 implies a high use of standardization practices: meets all three attributes. 


i. Survivability 

This attribute is a measure of an architecture's capability of operating in a 
mobile/transportable environment in support of warfighting missions. The driver also 
considers malicious attacks on the system by either conventional or informational 


methods. The rating for survivability is: 


¢ 1 implies architecture cannot operate in a mobile / transportable environment 


¢ 2 implies the architecture can operate effectively in a mobile / transportable 


environment. 
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j. Technical Risk 

The technical risk is determined by evaluating the current state of technology 
versus the technology necessary to employ a proposed candidate architecture. The risk 
involved is the risk of developing the technology in the time frame necessary to support 


employment of a new system. The rating scale for technical risk 1s: 


¢ 1 implies High: major technical problems to resolve 
e 2 implies Medium: moderate technical problems to resolve 


e¢ 3 implies Low: only minor technical problems to resolve. 


k. Training 
This attribute allows for the direct connectivity between the space vehicle 
operations center and the space vehicle control simulation systems (training facilities). 


The rating for this attribute 1s: 


¢ 1 implies no standardized interfaces for interactive training or direct 


connectivity between operations centers and training centers 


e 2 implies implementation of standardized interfaces for interactive training and 


support for direct connectivity between operations centers and training centers. 


2. Development of an Equal Weighted Ranking Matrix 
The authors evaluated the AFSCN, MCC, and the NAVSOC architectures using 


the eleven system / performance drivers and the rating scale presented in the previous 
section. The results are presented in Table 3, Equal Weighted Ranking of TT&C 
Architectures. This ranking assumes that all the performance drivers are of equal weight. 
As a result of completing Table 3, NAVSOC is revealed as the most favorable candidate 


architecture based on its level of performance. 
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TT&C Drivers 
Flexibility 









MCC NAVSOC 


Survivability 


Technical Risk 
Unweighted Score 


Unweighted Ranking 3 
Table 3, Equal Weighted Ranking of TT&C Architectures 


Information Timeliness 


NO 





C. RELATIVE SIGNIFICANCE OF SYSTEM / PERFORMANCE DRIVERS 


Since the development of Table 3 assumed that all weights were of equal 
importance, the next step would be to determine how to assign weighting factors to the 
individual performance / system drivers. Recall that in Section A of this chapter, AHP 
was indicated as the method to achieve this task. While a more complete description of 
AHP can be found in Reference 13, Section A further states the description for this 


process. 


1. Pairwise Comparison of Drivers 


The task of weighting the performance / system drivers begins with identifying a 
working group, consisting of a variety of system experts, and an established scaling 
criteria. The final result of the working group is a scaled driver relationship obtained 
through pairwise comparison. This method of comparison forces a subjective opinion on 
how well one attribute stands against another. A list of attributes can then be prioritized 


from highest to lowest in relative importance. 
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In an attempt to illustrate this procedure, a working group consisting of Naval Post 
Graduate School students from the Space Systems Operations curriculum was utilized. 
This working group was provided a survey questionnaire which enabled them to conduct 
a pairwise comparison of the eleven identified critical drivers. A complete copy of the 
survey questionnaire is provided in Appendix D. ‘Table 4, The Rating Scale, was 


provided to the working group as the agreed upon method of scaling. 


Extremely More Important 
Strongly More Important 


[6 | __Siightly More important 















Strongly Less Important 
Extremely Less Important 


Table 4, The Rating Scale 





To achieve a graphical representation, a pairwise comparison matrix based on the 
number of critical attributes is created. In this illustrated example, an eleven by eleven 
matrix was developed which matches the number of critical drivers identified. The axis 
of this matrix list these eleven drivers and provides a space to record the value of each 
pairwise comparison derived from the data collected from the survey questionnaire. The 
results of the working group survey questionnaire is presented in Table 5, Relative 


Significance Of TT&C Drivers. 
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Table 5, Relative Significance of TT&C Drivers 
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2. Development of Normalized Driver Relationship Table 


To further aid in the ease of presentation it is beneficial to normalize Table 4-3. 
This is accomplished by summing the individual columns and then dividing each entry in 
the column by the column sum. Table 6, The Normalized Relative Significance of 
TT&C Drivers, is the product of this procedure. Prior to calculating the weighted ranking 
of candidate architectures, the means from each row of the normalized table must be 
computed. The mean of each critical driver is shown in its own separate line at the 
bottom of Table 6. 

After completing the table, it revealed that the three most important drivers were 
Reliability, Survivability, and Information Timeliness. Additionally, it showed that the 
least favorable driver was Relative Cost which would indicate a tendency for it being an 
ideal trade off candidate. These results could be explained by examining the actual 
survey group utilized to produce the data. This group consisted of active duty personnel 
from varying armed force services. As such, they are more concerned with user driven 
performance of a system vice engineers who stress the technical impacts or 
developmental potential of that system. The placement of emphasis on these attributes 


will contribute to the creation of a weighted ranking in the following section. 
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D. DEVELOPMENT OF A WEIGHTED RANKING 


The conclusion of this process entails the development of the weighted ranking of 
the proposed candidates. This becomes the essential decision tool that can be graphically 
represented in a table format for the decision maker. This involves multiplying the 
unweighted ranking values of the decision alternatives with the mean relative significance 
values of individual criteria's (i.e. system / performance drivers). To continue with the 
illustrated example, the unweighted values from Table 3 and the mean values located in 
Table 5 were computed as per the above procedure. The result being the formation of 
weighted values which are presented in Table 7, The Weighted Ranking. Simply adding 
the values in each column results in each architectures weighted score. The weighted 
ranking is determined by numerical ranking of the individual scores. This means that the 

highest weighting score ranks first, the lowest score would rank last and all others fall 
somewhere between. 

The weighted ranking displayed in Table 7 shows the preferred candidate 
architecture to be NAVSOC, followed by MCC and AFSCN, respectfully. This matches 
the results found in Table 3 which were developed with the equal weighted ranking as a 
first approximation. It should be noted that what has been presented is an illustrated 
example. A more diverse survey group could possibly achieve a different conclusion. 
Even with this survey group the resulting value that separated first and second place 


candidates was a mere 0.0856 . 


13 
















NAVSOC 


0.0907 
0.2775 
0.2044 
0.2928 
0.1472 
0.222 

0.1814 


Standardization 0.084 0.168 0.168 






0.2082 
0.169 
0.178 
2.0786 


Table 7, Weighted Ranking of TT&C Architectures 


E. EVALUATION OF THE COST HIERARCHY 


_ The decision maker's ability to choose a proposed decision alternative is motivated 
not only by performance but cost concerns. The final stage in AHP instructs the decision 
maker to weigh performance versus cost of each candidate. The previous sections gave 
the decision maker the ability to grade an architectures performance. It is essential to 
understand that there exists a cost for that associated performance level. To aid ina cost 
analysis of TT&C architectures, a cost hierarchy model was developed. This model 
stresses specific areas where significant cost is incurred within any given architecture. 
Figure 13, The Cost Analysis Model, indicates four major areas determined by the 
authors to be essential. The majority of cost in an architecture occurs during its 
development, setup and production, and its continued operations and maintenance. It is 
also important to note that unforeseen cost will occur and the model provides for this in 


an area labeled Uncertainty. 
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Figure 13, The Cost Analysis Model 


F. SUMMARY 


The methodology presented in this chapter provides the decision maker with an 
objective approach to evaluate potential future as well as current TT&C architectures. 
An illustrated example was provided with each step to aid in clarification of the 
procedures involved. The chapter also gave a brief insight into the cost analysis model 
associated with TT&C environment. Coupled with the information contained in Chapters 
If and IfI, a foundation has been established which will provide a substantial aid in any 


future decisions concerning TT&C architectures. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY 


The intention of the authors was to focus the research into a format usable by a 
decision maker to aid in the selection of future TT&C architectures. As can be seen in 
the layout of the chapters, this was achieved through four distinct steps. These steps act 
as a capable aid by providing the following: better understanding of the process involved 
in TT&C; knowledge of what is available by identification of current architectures; 
comprehension of developing trends which will be seen in the proposed candidates; and 


demonstration of an objective methodology which can be used for evaluation. 


1. The TT&C Process 


In Chapter II, the first step in aiding the decision maker was accomplished by a 
descriptive illustration of the TT&C process. A better understanding would provide a 
foundation capable of allowing a more informed decision. The authors were able to 
identify and illustrate the interrelationships of primary and associated functions as they 


pertain to a generic TT&C architecture. 


2. Current Architectures 

The goal of the second step was to inform the decision maker of current TT&C 
architectures. Chapter III reviewed three of these architectures: Air Force Satellite 
Control Network (AFSCN), Mission Control Center (MCC), and Naval Satellite 
Operations Center (NAVSOC). The architectures chosen represented varying methods of 
conducting TT&C. 


3. Trends In TT&C Architectures 


In addition, Chapter III highlighted the trends in TT&C architecture development 
based on DOD policies and existing architectures. This third step would alert those 


involved in the evaluation process to what TT&C developments can be expected or 
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required in future proposals. The following trends were identified and should be regarded 


for future developing architectures: 
(1) automation 
(2) Commercial Off The Shelf (COTS) 
(3) distributed systems 
(4) open architectures 
(5) plug-in-use 
(6) graphic operator interfaces 
(7) use of the Open System Interconnection (OSI) Model 


4. The Methodology and Illustration 

The last step focused on providing a method for objective evaluation of TT&C 
architectures. Through discussions in Chapter IV, critical performance and system 
drivers were identified. The Analytic Hierarchy Process (AHP), an evaluation tool, was 
then applied. To aid in the comprehension of how AHP appplies, an illustrative example 
was provided. The example utilized the AFSCN, MCC, and the NAVSOC architectures 


that were described in Chapter III. 


B. CONCLUSIONS 

The authors offer the decision maker an alternative approach in evaluating current 
and future TT&C architectures. The benefit of their proposed methodology lies in its 
ability to be applied to architectures of varying design and complexity. Developing 
TT&C systems will take advantage of new state-of-the-art technologies. It is this 


technology evolution that the methodology specifically addresses. 
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This method is presented in its most basic form. It has the potential for further 
growth. As new drivers or trends are realized, it is a simple process to incorporate them 
and achieve meaningful results. The authors note that a thorough cost analysis of 
candidate TT&C architectures should be performed in conjunction with the use of this 
methodology. This would provide a complete cost and operational effectivness analysis 


(COEBA). 


C. RECOMMENDATIONS 


The methodology presented in this thesis represents the first prototype of an 
objective tool for evaluating alternative TT&C architectures. It is the authors opinion that 
there exist multiple areas that could be further expanded. The most obvious areas include 


the following: 


(1) Further development of the TT&C process model to include additional 


analysis of lower levels associated with sub-functions already presented. 


(2) Development of a thorough cost modeling hierarchy for a generic TT&C 


architecture. 


(3) Conduct additional surveys with technical experts as well as other users 
concerned with TT&C development for the purpose of validating the 


method proposed in this thesis. 
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APPENDIX A. TT&C PROCESS SYSTEM ANALYSIS DIAGRAMS 
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APPENDIX B. DATA DEFINITIONS 


Alarms: Pre - programmed indicators which detect adverse anomalies that exceed 
established space vehicle and/or ground facility limitations. 

Available Assets: A list of current status and availability of resources allocated to the 
TT&C facility which can be utilized for future planning. 

Commanding: This is the uplink information required to instruct a SV for the purpose of 
controlling mission execution or maintaining operability. This information typically 
includes synchronization code, spacecraft address bits, command message bits , and error 
check bits. 

Computer Hardware & Software: Advanced computational equipment and associated 
software required to carry out such activities as scheduling, analysis, evaluation and 
system simulations. 

Constellation Adjustment: Requirements, based on current constellation coverage, 
used to formulate recommended actions to ensure maintaining a specified fission 
coverage. 

Contact Objectives: Commanding objectives, in order of priority, desired to be 
formulated into command code and sent during establishment of communication lock 
between SV and ground facility. 


Contact Status Summary: A descriptive summary of actions taken during a mission 


contact phase. 








Contact Track: The initial establishment sf a lock-on between a space vehicle 
and its ground facility's tracking network. 

Deployment Plan: A generated order of tasking requirements for a specific space force 
deployment. Included in this plan would be the following: support pre-launch 
preparations, launch support, early orbit check out, positioning of space assets on - orbit, 
request for data, movement of spares, and repositioning for coverage. 

Detected Problem: Identification of an observed malfunction or abnormality discovered 
in either the SV and/or component of the ground segment. 

Distributed Mission Data: Mission essential data in the final format desired by the 
original tasking user. 

Facilities: Those structures that directly contribute supportive roles necessary for 
successful TT&C. Examples range from remote antenna sites, training classrooms, 
administration buildings and maintenance shops. 

Evaluation Results: Specific outcome of an overall system performance evaluation 
concerning a SV and the supporting ground segment. 

Evaluation / Status Reports: An external report generated for dissemination to outside 
commands and non-DOD users. Information contained may include position and current 
status of mission SV and their control assets. 

Ground Health & Status: Specific data that is queried from participating ground 
facilities that contribute in determining the current Health and Status of the ground 


segment. 
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Ground Performance Report: Pertinent ground segment information which would be 
used in analysis of overall performance. 

Ground System Status: A list of the current states of critical system components and 
associated parameters. 

Identified Action: The corrective actions presented to an operator as a recommendation 
in response to a detected problem. 

Internal Reports: A series of in-house generated reports essential for smooth 
operations within a TT&C facility. Possible examples include: Capacity Management 
Report, which graphically represents current network loading and utilization data and 
compares it with the theoretical capacity modeling, Ground Segment Evaluation Report, 
and SV System Evaluation Report. 

Immediate Recommended Actions: These are tasks to an operator to perform specified 
routines to accomplish a necessary action or in response to an identified problem. These 
actions are associated with time sensitive requirements that cannot be satisfied through 
the normal scheduling or schedule addition process. 

Logistic Schedule: Outlines the use of supporting elements of a non - flight essential 
nature after receiving initial requests for specific material resources and support to assist 
in completion of scheduled maintenance. 

Maintenance Asset Status: Indicator of ground segment hardware and software status. 


Includes operator workstations, processors, software, and simulators. 
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Mission Data: Data taken from the downlinked telemetry stream which is mission 
specific. 

Mission Need Statement (MNS): SV specific, the MNS details qualitative mission 
objectives which the SV must achieve to be useful to the user/warfighter. 

Modified Schedule: The result of scheduling deconflictions used in formulating a 
schedule modification. 

Non-immediate Recommended Actions: These are tasks to an operator to perform 
specified routines to accomplish a necessary action or in response to an identified 
problem. The actions can be satisfied through the normal scheduling or schedule 
addition process. 

Operations Plan: The compilation of all plans required to properly perform TT&C. 
Examples would include: Mission Plan, Schedule Plan, Training Plan, and Maintenance 
Plan. 

Operator Assignment: Operator to operation allocation. 

Personnel: The human element required to accomplish all aspects of executing and 
supporting TT&C. Some examples would be the following: Operators, training 
instructors, administrators, and technicians. 

Personnel Qualification Status: Represents current status of operator qualifications and 
the expiration date of each qualification. 

Pointing Data: Information necessary to allow the tracking network to gain proper 


orientation to establish a reliable uplink capability. 
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Positioning Data: Current ephemeris data derived from the processed tracking data. 
Predicted Position: Ephemeris data based on computations of a future timeline. 
Recommended Actions: These are assigned tasks to an operator to perform specified 
routines to accomplish a necessary action or in response to an identified problem. 
Reconfiguration Plan: A specific mission plan based on user and SV requirements that 
would initiate proper configuration of the SV. 

Resource Configuration: Resources required of the SV control network in order to 
perform scheduled missions. This would address the Network Utilization Schedule that 
outlines the operator to operation tasking and network configuration assignments. In 
addition, all items required to ensure a successful communication connectivity throughout 
the space control network would be involved. 

SV Health & Status: Specific data taken from the downlinked telemetry that pertains to 
the current health and status of a SV. 

SV Performance Report: Pertinent platform / payload information which would be used 
in analysis of overall performance. 

SV System Status: A list of the current status of critical system components and 
associated parameters. Specific data that contributes to the determination of the current 
SV health and status. 

Schedule Modification: An identification of specific mission tasking required to be 


incorporated within the scheduling process. 
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Schedule Options: Consist of several schedule considerations the result of user tasking 
and Non - Immediate Recommended Actions. 

Space Policy: Those space specific political and economic guidelines set forth by the 
following: Current Administration, Congress, and DOD. 

Space Vehicle Requirements: Closely related to the SV MNS, SV requirements contain 
succinct, well-defined, critical functional and operational elements. 

Specific Commands: Those commands necessary in accomplishing the pre determined 
contact objectives, maintaining Health & Status, and orbital orientation. 

Support Needs: Contains specific supporting request for items necessary in carrying out 
the support functions identified mission area such as Training, Maintenance, Logistics, 
and Supply. 

Support Requirement: Include the specific items such as, packaging, handling, 
transportation, depot / system technical orders, configuration control, and sparing 
strategies. 

Telemetry Data: This is the downlinked information received by the processing center 
which pertains to the health, status, and mission performance of the SV. Mission related 
data, which was collected by the SV, is digitized and downlinked in conjunction with the 
previously mentioned information. 

Time Sync: For support of attitude control, commanding, and time - tagging. Time sync 


may be supplied by either computer maintained counters or hardware timers. 
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Tracking Data: This is information required to precisely determine a SV location and 
velocity with respect to the tracking facility. The data consists of time, elevation, azimuth, 
range, and range rate. 

User Feedback: The necessary connectivity which allows for the interface between the 
user / warfighter and the control system. Directly contributes to the overall quality 
assurance of the SV control system. 

User Tasking: A request by the user / warfighter for either time critical or routine 
mission tasking. Possible requests include either Reconfiguration Request or Schedule 


Addition Request. 
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APPENDIX C. MCC SUPPORTING ANTENNAS 


1. C - Band Antennas 


Location 
FPS-16 


t. Huachuca, Scott Peak, AZ 

onathan Dickinson, FL 

aera Point, Hl 
FPS-16, FPS-16V 


PS-16 


DFRC, CA FPS-16, FPD-16 
EPS- 
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2. S- Band Antennas 


Alamo Peak, WSMR,NM(7SMAZEL 
Atom Peak, NOscurra Pk, NM |7.3M,AZ-EL 
Bermudalsiand SOMA XYNS OMX EW 
Colorado Springs, CO OMAZEL 
DiegoGarcia—SC*dTOMAZEL 
Dryden, DFRC, CA 43M AZEL 
Goldstone, CA SSC*dGMA XY N-S OMY EW 
Jonathan Dickinson, FL (| 85ft, AZ-EL__—_S0ft, AX-EL 

















© 















Tidbinbila, Australia __[26M, X-V, E-W 
Vandenberg AFB,CA ————|10M, AZ-EL 14M, AZ-EL 


3. Optical Camera 


Maul SSSC«*Camra 
Santa Yenez Peak, CA” [Camera 
Tranquifion Peak, CA [Camera 









Description 
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APPENDIX D: SURVEY QUESTIONNAIRE 


Survey Questionnaire 


EXTREMELY STRONGLY MODERATELY SLIGHTLY EQUALLY SLIGHTLY MODERATELY STRONGLY EXTREMELY 
MOR MORE MORE IMPORTANT LESS LESS LESS 


MORE LESS 
IMPORTANT IMPORTANT | IMPORTANT IMPORTANT IMPORTANT IMPORTANT = IMPORTANT — IMPORTANT 





Standardization is _ than Flexibility. 
_____ than Capacity. 
____ than Reliability 
_____ than Reporting & Tasking 
____ than Information Timeliness 
____ than Training 
_____ than Survivability 
____ than Relative Cost 
_____ than Technical Risk 
_____ than Maturity 


Flexibility is _____ than Capacity 

___ than Reliability 
than Reporting & Tasking 
than Information Timeliness 
than Training 
than Survivability 
than Relative Cost 


PELL 


than Technical Risk 
than Maturity 
Capacity is than Reliability 
than Reporting & Tasking 


than Information Timeliness 
than Training 

than Survivability 

than Relative Cost 

than Technical Risk 

____ than Maturity 
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8 


STRONGLY 
MORE 
IMPORTANT 


9 7 


EXTREMELY 
MORE 
IMPORTANT 


MORE 


Reliability is 


MODERATELY 


IMPORTANT 





Survey Questionnaire 


4 


3 


6 


SLIGHTLY 
MORE 


©) 


EQUALLY 
IMPORTANT 


SLIGHTLY 
LESS 


IMPORTANT IMPORTANT 





than Reporting & Tasking 


_____ than Information Timeliness 
___ than Training 

_____ than Survivability 

____ than Relative Cost 

_____ than Technical Risk 

_____ than Maturity 


Reporting & Tasking is 


Information Timeliness is 


Training is 


Survivability is 


Relative Cost is 


Maturity is 


than Information Timeliness 
than Training 

than Survivability 

than Relative Cost 
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1. Definition of Terms 


a. Capacity 


Capacity allows for the following: advanced capacity management planning ability; data 
rate easily variable to 25 Mbps based on user needs; and distributed open computing 


environments for easily expandable data processing capability. 


b. Flexibility 


Flexibility is a driver that takes into account automated mission planning and or 
scheduling; easily expandable and reconfigurable communications capability; secure system 
configurations to allow for operations across all classification levels; and lastly distributed open 


computing environments to allow rapid operational changes. 


c. Information Timeliness 


This driver is a measure of the architectures ability to satisfy all requirements levied on 


the space vehicle's control system by operational tasking in a timely manner. 


d. Maturity 


Maturity is a measure of the state of development of the proposed architecture. If the 
architecture is or has been operating in a fully operational mode then the candidate may be 
considered mature. If the candidate is based on technology under development and does not 


currently exist, then the architecture is in a concept state and cannot be considered mature. 


e. Relative Cost 

Relative cost is the cost to research the technical issues, develop, test and field the 
proposed TT&C architecture. 

f. Reliability 


That architecture which exhibits the following: expandable high data rate distributed 
workstations and broadened communications network; automated error detection and correction: 


and no mission impacting single point of failure. 
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g. Reporting & Tasking 

Reporting and tasking takes into account the following: distributed open computing 
environment with interface to existing external standard command and control systems for near 
real-time reporting and current status updates based on operational requirements, and distributed 
open computing environment with interface to external standard command and control system 


for near real time tasking response based on operational requirements. 


h. Standardization 

The standardization of a TT&C architecture looks at the standard interfaces for all 
applications within the system and to all external users. The driver also takes into account 
minimum need for dedicated resources or payload specific configurations. Finally the driver 
takes into account for standard communications protocols and interfaces for voice, data, and 


video. 


i. Survivability 
This driver is a measure of an architectures capability to operate in a mobile and or 
transportable environment in support of warfighting missions. The driver also considers 


malicious attacks on the system by either conventional or informational methods. 


j. Technical Risk 


The technical risk is determined by evaluating the current state of technology versus the 
technology necessary to employ a proposed candidate architecture. The risk involved is the risk 
of developing the technology in the time frame necessary to support the employment of a new 


system. 


k. Training 


This driver allows for the direct connectivity between the space vehicle operations 


center and the space vehicle control simulation systems (training facilities). 
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